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Application of Daniel Scott Jorgenson 
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I. REAL PARTY IN INTEREST 

The real party in interest of the instant application is Hewlett-Packard Development 
Company, a Texas Limited Liability Partnership having its principal place of business in 
Houston, Texas. 

II. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences. 

in. STATUS OF THE CLAIMS 

Claim 1-29 are pending in this application. As all claims 1-29 were rejected by the 
FINAL Office Action, all pending claims are the subject of this appeal. The Office Action 
rejected claims 1-8 and 12-26 under 35 U.S.C. § 102(b) as allegedly anticipated by U.S. 
Patent 6,253,248 to Nakai (hereafter Nakai). The Office Action rejected claims 9-11 and 
27-29 stand rejected under 35 U.S.C. § 103(a) as allegedly obvious over the combination of 
Nakai and a selective combination of elements from U.S. Patent 5,706,507 to Schloss 
(hereafter Schloss) 

IV. STATUS OF AMENDMENTS 

No amendments have been made or requested since the mailing of the FINAL Office 
Action and all amendments submitted prior to the FINAL action have been entered. A copy 
of the current claims is attached hereto as Appendix A. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

Embodiments of the claimed subject matter are illustrated in FIGs. 5A through 7B and 
are discussed in the specification at least at paragraphs 0054-0139. 

As embodied in claim 1 , a computer system comprises one or more client computers 
(see e.g., ref. num. 510 and related description) connected to a global-area computer 
network (see e.g., ref. num. 530 and related description), a transport gateway computer 
(see e.g., ref. num. 540 and related description) connected to the global-area computer 
network (see e.g., ref. num. 530 and related description), a plurality of server computers 
(see e.g., ref. num. 570A and 570B and related description) connected to the transport 
gateway computer (see e.g., ref. num. 540 and related description), and a transport 
gateway computer program executable by the transport gateway computer (see e.g., ref. 
num. 540 and related description). The transport gateway computer program comprising 
computer instructions for receiving a file transfer request (see e.g., FIG. 6 A and related 
description) from a client computer (see e.g., ref. num. 510 and related description), 
selecting a repository on one of the server computers (see e.g., ref. num. 570A and 570B 
and related description) based on one or more routing tokens in the file transfer request, 
wherein the routing tokens include one or more attributes describing the file, the client 
computer or an originator of the file transfer request, and performing the requested file 
transfer. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-8 and 12-26 stand rejected under 35 U.S.C. § 102(b) as allegedly 
anticipated by U.S. Patent 6,253,248 to Nakai (hereafter Nakai). 

Claims 9-11 and 27-29 stand rejected under 35 U.S.C. § 103(a) as allegedly obvious 
over the combination of Nakai and a selective combination of elements from U.S. Patent 
5,706,507 to Schloss (hereafter Schloss) 

VII. ARGUMENT 
The Rejection of Claims 1-8 and 12-26 Should be Overturned 

Claims 1, 12, and 19 are each independent claims. Claims 2-8, 13-18, and 20-26 
depend from claims 1, 12, and 19, respectively. Each of the independent claims 1, 12, and 
19 include an element that, for purposes of this appeal, commonly distinguishes the claimed 
embodiments of the invention over the cited art of record. For this reason, this section of 
the Appeal Brief will address only claim 1 , with the understanding that the argument made 
with respect to claim 1 is applicable to claims 2-8 and 12-26 as well. Thus, for at least the 
reasons set forth below in connection with claim 1, the Board should overturn the rejection 
of claims 1-8 and 12-26. 

Independent claim 1 recites: 

1. A computer system comprising: 

one or more client computers connected to a global-area computer 
network; 

a transport gateway computer connected to the global-area 
computer network; 

a plurality of server computers connected to the transport gateway; 

and 

a transport gateway computer program executable by the transport 
gateway, the transport gateway computer program comprising computer 
instructions for: 

receiving a file transfer request from a client computer; 
selecting a repository on one of the server computers based 
on one or more routing tokens in the file transfer request, wherein 
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the routing tokens include one or more attributes describing the 
file y the client computer or an originator of the file transfer 
request; and 

performing the requested file transfer. * 

{Emphasis added.) Applicant respectfully submits that the rejection is misplaced for at least 

the reason that the cited art does not disclose the features emphasized above. 

Specifically, among other features, claim 1 defines "selecting a repository on one of 

the server computers based on one or more routing tokens in the file transfer request, wherein 

the routing tokens include one or more attributes describing the file, the client computer or 

an originator of the file transfer request." The Office Action (paragraph No. 5) has alleged 

that this feature is taught in Nakai in col. 3-line 53 through col. 4, line 14, col. 5, lines 35-42, 

and col 7 line 37 — col. 8, line 9. Applicant respectfully disagrees. In contrast, this portion of 

Nakai actually states: 

The operation of the proxy server in FIG. 1 will be briefly 
described below. When the transmitter/receiver 101 has received a request 
from the client 107, the request is passed to the request 
interpreting/executing unit 102. The request interpreting/executing unit 102 
checks a protocol that the server as the destination of the request supports, 
and executes protocol conversion if necessary. 

In this case, information contained in the request from the client 
alone is often insufficient to execute conversion to the protocol that the 
destination server supports. In such case, information or the like on the 
user context holding unit 104 or local disk 108 is read out, or the setup 
window controller 106 presents the setup window on a display of the client 
107 to request the user to input necessary information, thus acquiring the 
information required for protocol conversion. 

The request interpreting/executing unit 102 inquires the server as to 
whether it has capability (resources) of satisfying the request or its 
resource state before it directly issues the request from the client to that 
server, and determines a server or system that can satisfy the request from 
the client most satisfactorily. 

In this way, the request interpreting/executing unit 102 issues a 
request after it specifies the necessary information and actual request 
destination, and then receives information sent back therefrom. Also, the 
request interpreting/executing unit 102 adds another information to the 
information sent back from the request destination, and sends them to the 
transmitter/receiver 101, which then sends back the data to the client 107. 
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The proxy server 100 receives a request from the client 107 by the 
transmitter/receiver 101 in step S301. The request interpreting/executing 
unit 102 forms data to be sent back to the Web browser on the basis of the 
received request (the respective processing operations in steps S302 to 
S304 and S306 to S309), and the transmitter/receiver 101 sends back the 
formed data to the Web browser (the processing in steps S305 and S3 10). 

* * * 

In step S500, the proxy server 100 checks using a file list get 
command if a file or directory named "/abc/def" is present in the CM 
server. According to the reply value of this command, it is determined 
that the above name indicates one of: 

a) a directory on the server; 

b) a file on the server, which is not checked out for modification; 

c) a file on the server, which is checked out for modification; and 

d) not present on the server. 

Subsequently, the flow advances to one of the following steps according 
to the determination result in the branch processing of steps S501, S502, 
and S504: 

step S503 (if the determination result is "a)") 

step S505 (if the determination result is "b)") 

step S506 (if the determination result is "c)") 

step S507 (if the determination result is "d)") 

The processing in step S503 will be explained below assuming 
that "/abc/def" is a directory name on the server. 

In step S503 , a list of file directory names present under the 
directory "/abc/def" on the CM server is acquired using a file list get 
command. Postulate that this command indicates there are three 
following files under the directory: 

xxx. html yyy.html zzz.html 

Then, the proxy server forms a text file described in the HTML 
language, as shown in FIG. 6. FIG. 6 shows an example of file list data 
formed by the proxy server in the first embodiment. The HTML 
language is the abbreviation for Hypertext Markup Language, is 
popularly used for displaying messages on the Web browser and the like, 
and is described in detail in references such as RFC- 1866. 

After that, the flow returns to the processing in step S3 10 in FIG. 
3, and the contents of the text file shown in FIG. 6 are sent back to the 
Web browser by the transmitter /receiver 101. Upon reception of the text 
file, the contents shown in FIG. 7 are displayed on the message display 
window of the Web browser. FIG. 7 shows the state wherein the Web 
browser displays the text file shown in FIG. 6. 

As can be verified from even a cursory review of this portion of Nakai, there is no teaching of 
the claimed feature, which is emphasized above. 
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More specifically, claim 1 defines a system for file transfer between geographically 
and organizationally distant end points (a "customer repository" aka "client computer" at one 
end, and a set of "supplier repositories" aka "server computers" at the other end). This system 
utilizes as many common off-the-shelf components as possible, as is noted in many places in 
the specification of the present application (see e.g., paragraphs 0067-0071). 

One unique component in the embodiments of the present application is what has 
been called the "transport gateway," and in particular its routing capability. The transport 
gateway resides between the client and the plurality of repository servers; when the client 
performs file transfer with a repository server of some kind, it connects to the gateway, not 
the repository server directly; rather, the gateway picks the right repository server (using the 
routing capability) and connects to it on the client's behalf. 

By this routing capability, the client does not have to know what repository server to 
connect, nor tell the transport gateway what repository server to connect. Instead, the client 
tells the gateway (by means of routing tokens included by the client in its request) some 
attribute(s) about the client context that the gateway will understand, and the gateway maps 
from those attribute(s) into the precise repository server that is appropriate for that context. 
For example, the client might provide routing tokens in its request describing the user itself: 
the type of organization (private business, government agency, etc), the type of business 
relationship the user has with the supplier of the gateway and repository server (support 
customer, vendor, etc), the scale of organization (small/home office, mid-size, enterprise, 
etc), the location of the user (e.g, country), etc.. As another example, the client might provide 
routing tokens in its request describing the file being transferred: the nature of its content 
(hardware diagnostic report, software inventory report, executable software, purchase order, 
etc), the name of the application that produced it or for which it is intended, etc. In each case, 
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these routing tokens "describe" the context of the particular client request. The gateway then 
chooses the right repository server that the supplier has designated as appropriate for handling 
file transfers for that context. This component (which component is more fully explained in 
the specification), among others, clearly defines claim 1 over the cited because it abstracts the 
repository servers to the client. Therefore, when repository servers change - which 
realistically happens all the time in a large supplier organization - the gateway's routing 
capability shelters the customer from that change. The customer merely continues to describe 
his request context in the same way, and the supplier merely changes the routing rules to 
adapt to the change in the repository server pool accordingly. This solves one of the major 
potential breakage points in any large-scale long-term data-exchange architecture (e.g., shifts 
in topology). 

In contrast to the features of claim 1, the teachings of Nakai are quite different. In this 
regard, and in contrast to the system of the present application, the system of Nakai is directed 
simply to an "information processing apparatus," in which a proxy server, disposed between 
the client and server, intervenes in communications between the client and server. In this 
regard, the proxy server specifies (using the precise IP address or server name of the end 
server, as specified by the client) a server based on the request, and determines the 
communication protocol to be used in the communication, (see Nakai, col. 5, line 47, which 
shows their client requests all specify the exact end-server machine name - or IP address). 
This is also suggested from all of the examples discussed in the Nakai spec - e.g., col. 5 lines 
13-15, col. 5 lines 51-65, col. 6 lines 55-65, etc. 

The foregoing description has been provided merely to assist in the understanding of 
an operation embodiment of claim 1 . For purposes of defining claim 1 over the cited Nakai 
reference, suffice it to say that Nakai fails to disclose the "selecting a repository . . . based on 
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one or more routing tokens..." element of this claim, and for at least this reason the rejection 
should be overturned. As emphasized in the quoted claim above, claim 1 of the present 
application defines "selecting a repository on one of the server computers based on one or 
more routing tokens in the file transfer request, wherein the routing tokens include one or 
more attributes describing the file, the client computer or an originator of the file transfer 
request." The Office Action (paragraph 4) alleges that these features are taught by Nakai at 
col. 6 lines 55-65, col. 7, lines 22-26, and col. 7, lines 37-56. Applicant respectfully 
disagrees. 

Significant distinctions between claim 1 and Nakai are manifest in the purpose and 
operation of the two different systems. For example, a purpose of embodiments of the 
present invention is for relaying content upstream or downstream through a gateway, in such 
a manner that the client does not have to know the identity (e.g., machine name, IP address, or 
other identifier) of the server at the far end of the relay. Instead,, the client describes 
something about itself to the gateway, and the gateway infers (or determines) an appropriate 
end-server from that, without the client's knowledge. This was emphasized Applicant's first 

response, in which Applicant stated: 

More specifically, claim 1 defines a system for file transfer 
between geographically and organizationally distant end points (a 
"customer repository" aka "client computer" at one end, and a set of 
"supplier repositories" aka "server computers" at the other end). This 
system utilizes as many common off-the-shelf components as possible, as 
is noted in many places in the specification of the present application (see 
e.g., paragraphs 0067-0071). 

One unique component in the embodiments of the present 
application is what has been called the "transport gateway," and in 
particular its routing capability. The transport gateway resides between the 
client and the plurality of repository servers; when the client performs file 
transfer with a repository server of some kind, it connects to the gateway, 
not the repository server directly; rather, the gateway picks the right 
repository server (using the routing capability) and connects to it on the 
client's behalf. 
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By this routing capability, the client does not have to know what 
repository server to connect, nor tell the transport gateway what repository 
server to connect. Instead, the client tells the gateway (by means of 
routing tokens included by the client in its request) some attribute(s) about 
the client context that the gateway will understand, and the gateway maps 
from those attribute(s) into the precise repository server that is appropriate 
for that context. For example, the client might provide routing tokens in its 
request describing the user itself: the type of organization (private 
business, government agency, etc), the type of business relationship the 
user has with the supplier of the gateway and repository server (support 
customer, vendor, etc), the scale of organization (small/home office, mid- 
size, enterprise, etc), the location of the user (e.g, country), etc.. As 
another example, the client might provide routing tokens in its request 
describing the file being transferred: the nature of its content (hardware 
diagnostic report, software inventory report, executable software, purchase 
order, etc), the name of the application that produced it or for which it is 
intended, etc. In each case, these routing tokens "describe" the context of 
the particular client request. The gateway then chooses the right repository 
server that the supplier has designated as appropriate for handling file 
transfers for that context. This component (which component is more fully 
explained in the specification), among others, clearly defines claim 1 over 
the cited because it abstracts the repository servers to the client. 
Therefore, when repository servers change - which realistically happens all 
the time in a large supplier organization - the gateway's routing capability 
shelters the customer from that change. The customer merely continues to 
describe his request context in the same way, and the supplier merely 
changes the routing rules to adapt to the change in the repository server 
pool accordingly. This solves one of the major potential breakage points in 
any large-scale long-term data-exchange architecture (e.g., shifts in 
topology). 

Nakai does not teach or even contemplate such a robust functionality. Instead, Nakai 
specifically teaches that the server machine name (and port) will be specified by the client 
(e.g., col 6 lines 62-63). The system of Nakai further describes the use of that same machine 
name (and port) to connect to the specified machine as the end-server (e.g. col 7 line 25, 
where "...the CM server...", which is the target of the proxy's request, is clearly the server 
whose server machine name was specifically given directly by the client as "CM" in col 6 line 
62). Nakai wholly fails to disclose or suggest a feature, whereby the client request does not 
itself identify the end-server machine by name and port. Rather, the system disclosed in Nakai 
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has the client request specify the end-server machine by name and port, but using a different 
protocol than that which is native to that end-server, so that protocol conversion is necessary 
(that being the essence of the invention — i.e., see 7 lines 20-21). 

In contrast, claim 1 of the present application defines a system having a "transport 
gateway . . . comprising computer instructions for . . . selecting a repository on one of the 
server computers based on one or more routing tokens in the file transfer request, wherein 
the routing tokens include one or more attributes describing the file, the client computer or 
an originator of the file transfer request" Further, the present application has defined 
routing tokens (see paragraph 0085 of the present application) as "tokens known to the 
Customer Repository and presented for purposes of Supplier Repository routing to the 
Transport Gateway. . .." Simply stated, the machine name, IP address, or other identifier of 
Nakai does not properly anticipate the "routing tokens," as this term must properly be 
construed for the claims of the present application. The Examiner has apparently ignored this 
definition of "routing tokens," by alleging that a filename could be used as a routing token. 
Specifically, in the Advisory Action, the Examiner stated "Examiner has given 'routing 
token' its broadest possible interpretation. Nakai teaches a filename being used to route a file 
request to a proper repository (directory) and thus the filename may be viewed as a routing 
token." This is wrong. Immediately following paragraph 0085 (in which Applicant defined 
"routing token"), Applicant defined "file name" (see paragraph 0086). The Examiner is not 
free to disregard the definition that the present application has specifically accorded to the 
term "routing token" and assign his own definition. The mere fact that the present application 
has specifically defined both "routing tokens" and "file names," and the claims specifically 
recite routing tokens, invalidates the application by the Examiner of a filename as comprising 
a "routing token." For this reason alone, the rejections should be overturned. 
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Another notable distinction between the invention of claim 1 and Nakai is observed 
in connection with the rejection in which the Office Action has applied the proxy server of 
Nakai as allegedly anticipating the claimed "transport gateway." This reflects a 
fundamental misunderstanding of claim 1 , and a misapplication of Nakai . Among other 
features, claim 1 recites: "a transport gateway computer connected to the global-area 
computer network;" and "a plurality of server computers connected to the transport 
gateway." In contrast, Nakai teaches that a "proxy server is present between the client and 
server, and intervenes in communication therebetween" (see Abstract). There is no 
teaching of the proxy server having a plurality of server computers connected to us (as the 
claimed transport gateway requires) . " This and other fundamental distinctions are apparent 
when considering the purpose and environment of the present invention, as contrasted 
between the purpose and environment of Nakai. In Nakai, the purpose is essentially 
protocol conversion (as opposed to a purpose of embodiments of the present invention, 
which is for relaying content upstream or downstream through a gateway, in such a manner 
that the client does not have to know the identity of the server at the far end). 

In short, and as noted above, the present (FINAL) Office Action ultimately repeated 
its previous rejections word-for-word. In responding to Applicant's previous remarks, the 
Office Action maintained its position by: 

1) equating the claimed repositories with Nakai 's use of directories; 

2) equating the claimed "routing tokens" with Nakai's use of a filename; and 

3) equating the claimed "transport gateway" with Nakai's use of a proxy server. 
These equated concepts are simply not similar and cannot be properly equated. For 
example, the claimed routing tokens describe the client so that the end-server can be 
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inferred by the transport gateway. However, in Nakai, the resource name must exactly 
match the name at the end server. 

Again, functional differences such as this underscore the significance of the claimed 
subject matter, such that the applications made by the Office Action cannot properly be 
sustained. 

For purposes of defining claim 1 over the cited Nakai reference, suffice it to say that 
Nakai fails to disclose the "selecting a repository . . . based on one or more routing tokens. . ." 
element of this claim, and for at least this reason the rejection should be overturned. For at 
least this reason, the rejection of claim 1 should be overturned. 

Dependent Claims 2-7 

Claims 2-7 each depend from claim 1 , and therefore patently define over the applied 
art for at least the same reasons described above. 

Claims 12-26 

Independent claims 12 and 19 contain an element that loosely corresponds to the 
"selecting ..." element of claim 1 that was discussed above. Thus, for at least the same 
reason discussed in connection with claim 1 above, claims 12 and 19 patently define over 
the cited art. Claim 13-18 and 20-26 depend from claims 12 and 19, respectively, and 
define over the cited art for at least the same reasons. 

The Rejection of Claims 9-11 and 27-29 Should be Overturned 
In addition to the fact that claims 9-11 and 27-29 depend from claims 1 and 19 
(respectively), and therefore patently define over the cited art for at least the same reasons 
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set forth in connection with claims 1 and 19 above, Applicant further traverses the rejection 

of claims 9-11 and 27-29 as improper. 

The Office Action rejected claims 9-11 and 27-29 as allegedly obvious over the 

combination of Nakai and Schloss. In forming this rejection, the Office Action merely 

concluded that the combination of these two references would have been obvious "because 

it offers the advantage of allowing the fetching of information by any authorized user . . . 

from any cooperating computer on the Internet by simply clicking on a link." (Office 

Action, paragraph No. 14). Applicants respectfully submit that this rejection falls far short 

of the legal requirements for forming rejections under 35 U.S.C. § 103(a). In this regard, 

it is well-settled law that in order to properly support an obviousness rejection under 35 

U.S.C. § 103, there must have been some teaching in the prior art to suggest to one skilled in 

the art that the claimed invention would have been obvious . W. L. Gore & Associates, Inc. 

v. Garlock Thomas, Inc. , 721 F.2d 1540, 1551 (Fed. Cir. 1983). More significantly, 

"The consistent criteria for determination of obviousness is whether the prior 
art would have suggested to one of ordinary skill in the art that this [invention] 
should be carried out and would have a reasonable likelihood of success, 
viewed in light of the prior art. ..." Both the suggestion and the expectation of 
success must be founded in the prior art, not in the applicant's disclosure. . . In 
determining whether such a suggestion can fairly be gleaned from the prior art, 
the full field of the invention must be considered; for the person of ordinary 
skill in the art is charged with knowledge of the entire body of technological 
literature, including that which might lead away from the claimed invention. 11 

(Emphasis added) In re Dow Chemical Company , 837 F.2d 469, 473 (Fed. Cir. 1988). 

In this regard, Applicants note that there must not only be a suggestion to combine the 
functional or operational aspects of the combined references, but that the Federal Circuit also 
requires the prior art to suggest both the combination of elements and the structure resulting 
from the combination. Stiftung v. Renishaw PLC , 945 Fed.2d 1173 (Fed. Cir. 1991). 
Therefore, in order to sustain an obviousness rejection based upon a combination of any two 
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or more prior art references, the prior art must properly suggest the desirability of combining 
the particular elements to create a message passing system as defined by the pending claims. 

When an obviousness determination is based on multiple prior art references, there 
must be a showing of some "teaching, suggestion, or reason" to combine the references. 
Gambro Lundia AB v. Baxter Healthcare Corp. , 110 F.3d 1573, 1579, 42 USPQ2d 1378, 
1383 (Fed. Cir. 1997) (also noting that the "absence of such a suggestion to combine is 
dispositive in an obviousness determination"). 

Evidence of a suggestion, teaching, or motivation to combine prior art references 
may flow, inter alia , from the references themselves, the knowledge of one of ordinary skill 
in the art, or from the nature of the problem to be solved. See In re Dembiczak , 175 F.3d 
994, 1000, 50 USPQ2d 1614, 1617 (Fed. Cir. 1999). Although a reference need not 
expressly teach that the disclosure contained therein should be combined with another, the 
showing of combinability, in whatever form, must nevertheless be "clear and particular." 
Dembiczak , 175 F.3d at 999, 50 USPQ2d at 1617. 

If there was no motivation or suggestion to combine selective teachings from 
multiple prior art references, one of ordinary skill in the art would not have viewed the 
present invention as obvious. See In re Dance , 160 F.3d 1339, 1343, 48 USPQ2d 1635, 
1637 (Fed. Cir. 1998); Gambro Lundia AB , 110 F.3d at 1579, 42 USPQ2d at 1383 ("The 
absence of such a suggestion to combine is dispositive in an obviousness determination. "). 

Significantly, where there is no apparent disadvantage present in a particular prior 
art reference, then generally there can be no motivation to combine the teaching of another 
reference with the particular prior art reference. Winner Int'l Royalty Corp. v. Wang , No 
98-1553 (Fed. Cir. January 27, 2000). The Office Action has failed to cite any apparent 

r 

disadvantage of Nakai, which would prompt the combination of select teachings of Schloss 
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therewith. Indeed, the Office Action has failed to identify a proper motivation for 
combining the teachings of Schloss with Nakai. 

For at least this separate and independent basis, the rejections of claims 9-11 and 
27-29 should be overturned. 



Based upon the foregoing discussion, Applicants respectfully requests that the 
Examiner's final rejection of claims 1-29 be overturned by the Board, and that the application 
be allowed to issue as a patent with all pending claims 1-29. 

Please charge Hewlett-Packard Company's deposit account 08-2025 in the amount of 
$500 for the filing of this Appeal Brief. No additional fees are believed to be due in connection 
with this Appeal Brief. If, however, any additional fees are deemed to be payable, you are 
hereby authorized to charge any such fees to deposit account No.. 08-2025. 



CONCLUSION 



Respectfully submitted, 




Daniel R. McClure 
Registration No. 38,962 



(770) 933-9500 
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VIII. CLAIMS - APPENDIX 

<§R' 1. A computer system comprising: 

one or more client computers connected to a global-area computer network; 
a transport gateway computer connected to the global-area computer network; 
a plurality of server computers connected to the transport gateway; and 
a transport gateway computer program executable by the transport gateway , the 
transport gateway computer program comprising computer instructions for: 

receiving a file transfer request from a client computer; 
selecting a repository on one of the server computers based on one or more 
routing tokens in the file transfer request, wherein the routing tokens include one or 
more attributes describing the file, the client computer or an originator of the file 
transfer request; and 

performing the requested file transfer. 



2. The computer system of claim 1 wherein the transport gateway computer 
program further comprises computer instructions for determining whether an originator of 
the file transfer request is verifiably known. 

3. The computer system of claim 1 wherein the transport gateway computer 
program further comprises computer instructions for determining whether an originator of 
the file transfer request is authorized to performed the requested file transfer. 

4. The computer system of claim 1, wherein the file transfer request is received by 
the transport gateway from the requesting client computer using a first communication 
protocol and the file transfer request is sent by the transport gateway computer to the 
selected repository using a second communication protocol. 
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5. The computer system of claim 1, wherein the transport gateway computer 
program further comprises computer instructions for: establishing a communication path 
between the transport gateway computer and the selected repository; and sending a 
corresponding file transfer request to the selected repository, including information 
forwarded from the requesting client computer's file transfer request. 

6. The computer system of claim 5, wherein the file transfer request is an upload 
request and the transport gateway computer program further comprises computer 
instructions for: relaying the file content from the requesting client computer to the selected 
repository; receiving a corresponding file upload response from the selected repository; 
forwarding information in the file upload response to the requesting client computer; and 
terminating the communication path between the transport gateway computer and the 
selected repository. 

7. The computer system of claim 5, wherein the file transfer request is a download 
request and the transport gateway computer program further comprises computer 
instructions for: receiving a corresponding file download response from the selected 
repository; forwarding information in the file download response to the requesting client 
computer; relaying the file content from the selected repository to the requesting client 
computer; and terminating the communication path between the transport gateway computer 
and the selected repository. 

8. The computer system of claim 1, wherein the requesting client computer 
connects to the transport gateway computer over the global-area computer network using an 
HTTP or HTTPS communication protocol and the transport gateway computer connects to 
the server computer storing the selected repository using an HTTP, HTTPS or FTP 
communication protocol. 

9. The computer system of claim 1, wherein the client computers connect to. the 
global-area computer network through a firewall and/or a proxy computer. 
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10. The computer system of claim 1, wherein the transport gateway computer 
connects to the server computers through a firewall and/or a proxy computer. 

11. The computer system of claim 1, wherein the global-area computer network 
connects to the transport gateway computer through a firewall and/or a proxy computer. 

12. A method of transferring file information between one or more client computers 
and one or more server computers over a global-area computer network, the method 
comprising: 

receiving a file transfer request from a client computer; 

selecting a repository on one of the server computers based on one or more routing 
tokens in the file transfer request, wherein the routing tokens include one or more attributes 
describing the file, the client computer or an originator of the file transfer request; and 

performing the requested file transfer. 

13. The method claim 12, further comprising determining whether an originator of 
the file transfer request is verifiably known. 

14. The method claim 12, further comprising determining whether an originator of 
the file transfer request is authorizedto performed the requested file upload. 

15. The method of claim 12, wherein the file transfer request is received using a 
first communication protocol and the file transfer request is processed using a second 
communication protocol. 

16. The method of claim 12, further comprising: establishing a communication path 
between the transport gateway computer and the selected repository; and sending a 
corresponding file transfer request to the selected repository, including information 
forwarded from the requesting client computer's file transfer request. 
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17. The method of claim 16, wherein the file transfer request is an upload request 
and the method further comprises: relaying the file content from the requesting client 
computer to the selected repository; receiving a corresponding file upload response from 
the selected repository; forwarding information in the file upload response to the requesting 
client computer; and terminating the communication path between the transport gateway 
computer and the selected repository. 

18. The computer system of claim 16, wherein the file transfer request is a 
download request and the method further comprises: receiving a corresponding file 
download response from the selected repository ; forwarding information in the file 
download response to the requesting client computer; relaying the file content from the 
selected repository to the requesting client computer; and terminating the communication 
path between the transport gateway computer and the selected repository. 

19. A computer-readable storage medium comprising a routing computer program 
executable by a transport gateway connected to one or more client computers and one or 
more server computers, the transport gateway computer program comprising computer 
instructions for: 

receiving a file transfer request from a client computer; 

selecting a repository on one of the server computers based on one or more routing 
tokens in the file transfer request, wherein the routing tokens include one or more attributes 
describing the file, the client computer or an originator of the file transfer request; and 

performing the requested file transfer. 

20. The computer-readable storage medium of claim 19, wherein the transport 
gateway computer program further comprises computer instructions for determining 
whether an originator of the file transfer request is verifiably known. 
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21. The computer-readable storage medium of claim 19, wherein the transport 
gateway computer program further comprises computer instructions for determining 
whether an originator of the file transfer request is authorized to performed the requested 
file transfer. 

22. The computer-readable storage medium of claim 19, wherein the file transfer 
request is received by the transport gateway from the requesting client computer using a 
first communication protocol and the file transfer request is sent by the transport gateway 
computer to the selected repository using a second communication protocol. 

23. The computer-readable storage medium of claim 19, wherein the transport 
gateway computer program further comprises computer instructions for: establishing a 
communication path between the transport gateway computer and the selected repository; 
and sending a corresponding file transfer request to the selected repository, including 
information forwarded from the requesting client computer's file transfer request. 

24. The computer-readable storage medium of claim 23, wherein the file transfer 
request is an upload request and the transport gateway computer program further comprises 
computer instructions for: relaying the file content from the requesting client computer to 
the selected repository; receiving a corresponding file upload response from the selected 
repository; forwarding information in the file upload response to the requesting client 
computer; and terminating the communication path between the transport gateway computer 
and the selected repository. 

25. The computer-readable storage medium of claim 23, wherein the file transfer 
request is a download request and the transport gateway computer program further 
comprises computer instructions for: receiving a corresponding file download response 
from the selected repository; forwarding information in the file download response to the 
requesting client computer; relaying the file content from the selected repository to the 
requesting client computer; and terminating the communication path between the transport 
gateway computer and the selected repository. 
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26. The computer-readable storage medium of claim 19, wherein the requesting 
client computer connects to the transport gateway computer over the global-area computer 
network using an HTTP or HTTPS communication protocol and the transport gateway 
computer connects to the server computer storing the selected repository using an HTTP, 
HTTPS or FTP communication protocol. 

27. The computer-readable storage medium of claim 19, wherein the client 
computers connect to the global-area computer network through a firewall and/or a proxy 
computer. 

28. The computer-readable storage medium of claim 19, wherein the transport 
gateway computer connects to the server computers through a firewall and/or a proxy 
computer. 

29. The computer-readable storage medium of claim 19, wherein the global-area 
computer network connects to the transport gateway computer through a firewall and/or a 
proxy computer. 
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IX. EVIDENCE - APPENDIX 

None. 
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IX. RELATED PROCEEDINGS- APPENDIX 



None. 



